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ABSTRACT 


The Defense Modeling and Simulation Office developed the Functional 
Description of the Mission Space (FDMS) Resource Center imder the guidance of DoD 
5000.59-P, DoD Modeling and Simulation Master Plan. The FDMS Resource Center 
provides a controlled repository for modeling and simulation (M&S) data and promotes 
data standardization and reuse. The Resource Center is currently operational at 
http;//38.241.48.9. 

Use of the FDMS Resource Center is voluntary on the part of DoD M&S 
organizations, although maximum use of the Center is paramount if standardization and 
reuse S 5 mergies are to be realized. In an effort to encourage more use of the Resource 
Center's capabilities, the author analyzed the Resoixrce Center, interviewed the Center's 
principals, and developed a set of requirements governing screenshot appearance, data 
workflow control, and privilege permission selections which should simplify and clarify 
the Center's user processes. 
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I. INTRODUCTION 


A. BACKGROUND 

The Defense Modeling and Simulation Office (DMSO) is a Department of 
Defense (DoD) agency which serves as a clearinghouse for modeling and simulation 
policies, guidance, and activities. It acts as the executive secretariat for the Executive 
Council on Modeling and Simulation and, among other specified duties, assists 
Department of Defense (DoD) Services and Agencies develop, acquire, and share 
modeling and simulation (M&S) technology, standards, and processes. 

A key document which guides DMSO's activities is DoD 5000.59-P, The DoD 
Modeling and Simulation Master Plan, dated October 1995. This document provides 
focus and direction to the entire DoD M&S community. Its six objectives address 
commonly shared concerns such as a common technical framework, authoritative 
representations of the natural environment, systems, and human behavior, and M&S 
education, resource repositories, and accreditation. 

DMSO responded to the three sub-objectives of the Modeling and Simulation 
Master Plan depicted in Table 1 by developing the Functional Description of the Mission 
Space (FDMS) Resource Center. The Resource Center, at its most basic, is a web-based 
products repository which allows users to register, control, and manage their digital 
models and simulations. It provides analysis tools, and can facilitate re-use and 
interoperability by transforming certain products into XML documents using a standard 
document type definition (DTD). 
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Sub-Objective 

Description 

1-2 

Develop conceptual models of the mission space 
(CMMS) to provide a common starting point for 
constructing consistent and authoritative M&S 

representations, and to facilitate interoperability and reuse of 

simulation components. 

1-3 

Establish data standards to support common 

representations of data in models and simulations. 

5-3 

Provide a repository system to facilitate developer 

and end-user access to modeling and simulation resources. 


Table 1. Selected Sub-Objectives from DoD 5000.59-P 


The DoD Modeling and Simulation Master Plan is almost six years old. It is 
currently being updated and is expected to be approved later this year. The new plan is 
anticipated to replace the current six main objectives with the five objectives listed in 
Table 2. The FDMS Resource Center, by design, actively supports the first and fourth 
objectives. 


Objective 

Description 

1 

Promote M&S standardization and reuse 

2 

Develop authoritative M&S representations 

3 

Provide and maintain supporting M&S infrastructure 

4 

Provide ready access to M&S resources 

5 

Improve the usability of M&S 


Table 2. Main Objectives of Draft DoD 5000.59-P 
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DMSO manages a related but separate cataloging effort called the Modeling and 
Simulation Resource Repository (MSRR). Whereas the FDMS Resource Center is 
designed to catalog military models of the mission space, provide analysis capabilities, 
and promote interoperability and re-use through a standard DTD, the purpose of the 
MSRR is to catalog, via a distributed system of resource servers, all products related to 
modeling and simulation. These products include, but are not limited to, models, 
simulations, databases, algorithms, documents, tools, and utilities. DMSO is currently 
orchestrating an effort to link some of the capabilities of the MSRR with the FDMS 
Resource Center in order to reduce redundancies and achieve synergy between the two 
systems. In fact, some of the requirements discussed in Chapter III are currently 
implemented in the MSRR. If the linkage between the MSRR and the FDMS Resource 
Center is successful, those requirements will not have to be re-implemented in the FDMS 
Resource Center. 

B. PURPOSE 

The FDMS Resource Center is functional and on-line at http://38.241.48.9. It is a 
tool provided by DMSO for the use of the Services' and Agencies' modeling and 
simulation organizations. There is no requirement that the Services and Agencies use the 
Resource Center. Therefore, the Resource Center will only provide value to the DoD if 
the Services and Agencies recognize that value and choose to register their M&S 
products with the Center and use the analysis and translation tools there. 

The FDMS Resource Center Project Manager (PM) recognizes the synergy which 
could develop if most DoD M&S organizations used the Center. To that end, the PM is 
concerned that the Resource Center be intuitive and easy to use. The Resource Center 
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provides users strict control of the products they register, and the PM wants to ensure that 
the workflow which makes available that strict control to be clear and unambiguous. 

The purpose of this thesis is to conduct an analysis of the FDMS Resource Center 
and, keeping the PM's goals in mind, provide a set of recommendations - herein called 
"requirements" - which will enhance the Resource Center's ease of use and improve 
users' perceptions of the proven capabilities of the Center. 

C. SCOPE AND METHODOLOGY 

This thesis concerns itself with the usability of the FDMS Resource Center web- 
based tool. It does not take into account the kind of data registered or stored in the 
Resource Center's repositories, nor does it assess the functionality of the Center's analysis 
tools or XML translation capability. 

The author developed the concept for this thesis after an initial interview with the 
FDMS Resource Center's project manager, Mr. Jack Sheehan. Mr. Sheehan arranged for 
the author a workspace in the offices of Resource Center's development contractor. 
Innovative Management Concepts, Inc. (IMC) of Sterling, VA. At IMC he was able to 
analyze the Resource Center on IMC's development server, read development documents, 
and confer daily with IMC's project manager and chief programmer/developer. From this 
vantage point the author was able to study and use the FDMS Resource Center and 
develop the requirements discussed in Chapter 3. 
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II. OVERVIEW OF THE FUNCTIONAL DESCRIPTION OF THE 
MISSION SPACE RESOURCE CENTER 


A. DESCRIPTION OF FUNCTIONS 

The FDMS Resource Center provides a number of functions to the M&S 
community, to include search capability of authoritative data sources, guidance on 
common syntax and semantics, and links to other M&S web sites. The main attraction of 
the Resource Center, however, is its FDMS Library. The Library consists of two M&S 
repositories: the Native Library and the Common Library. Each library consists of digital 
modeling and simulation products of the U.S. military's functional description of the 
battlespace. 

1. Native Library 

The FDMS Native Library consists of the M&S files which the user submits to 
the repository. A Native Library product may be a word processor file describing a real- 
world process, a set of slides illustrating an IDEF model, or executable code. The digital 
models and simulations are stored imchanged from their original form; hence, it is the 
Native Library because the files are maintained in their native format. 

This is not to say that the files are fixed in the Library forever. As described 
below, users have control over the models and simulations they register in the Library. 
Users can remove from the Library models and simulations they deem obsolete or no 
longer accurate. Conversely, a user can modify his file and resubmit it so that it replaces 
the original file or exists with the original file providing a configuration management trail 
and record. 
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The Native Library contains search tools to enable the recovery and re-use of 
existing models and simulations. It also provides controls with which the originating user 
can regulate the use of his products. 

2. Common Library 

The FDMS Common Library provides the FDMS with its re-usability and 
interoperability functions. Some Native Library products can be converted into a 
"common" product using the FDMS XML Data Interchange Format (DIF) and then 
stored in the Common Library. Models and simulations in the structured format provided 
by the FDMS XML DIF can then be more thoroughly analyzed, creditably compared 
with other documents in the same format, and will more likely interoperate. The 
likelihood of reuse of developed models and simulations is enhanced as well. 

As with the Native Library, users have control over who has access to their M&S 
products. 

B. TYPES OF USERS 

The FDMS Resource Center defines four types of users (not including the FDMS 
Administrator who is not discussed in this thesis) as shown in the Resource Center screen 
shot in Figure 1. These user types are not mutually exclusive - every Resource Center 
user can act as a Producer, Consmner, and Examiner, and a selected few are designated as 
Sponsors as well. 

1. Sponsor 

The Sponsor is the kingpin of the FDMS Resource Center. Sponsors are assigned 
by the Resource Center Administrator after a positive check with the potential Sponsor’s 
organization that the candidate is an M&S principal who requires Sponsor privileges. 
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Sponsors not only have control of who has access to FDMS products, but they also 
control who has access to the FDMS libraries. Through the use of privileges, the Sponsor 
approves who may submit M&S products (called the "Producer") and who may view or 
use them (called the "Consumer"). He may also assign a user (called the "Examiner") to 
review or analyze a product. 



Accr«dK 


I CrnUfy 

I Examiner 

Figure 1. Users of the FDMS Libraries. 

2. Producer 

The Producer, of course, also has a large role in the FDMS Resource Center — he 
submits the products for registration and inclusion in the libraries. The Producer 
develops the products outside the Resource Center, and his submissions are controlled by 
a governing Sponsor. 
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3. 


Consumer 


The Consumer is the actual user of an M&S product registered in the FDMS 
Resource Center. As stated above, a Consumer can gain access to a product only with the 
explicit permission of the governing Sponsor. 

4. Examiner 

The Native and Common Libraries provide the capability for the Sponsor to 
assign a product to a user for that user to analyze, verify, validate, accredit, or certify. 
That user, when he gets these missions, is the Examiner. Some tools to assist in these 
functions are provided in each of the FDMS libraries. 

C. USE CASES 

A few representative use cases will illustrate the relationship the different users 
have with each other as well as partially demonstrate the need for the requirements 
analysis in Chapter III. 

1. Register a Product 

The first use case describes the process to register a digital product in the FDMS 
Resource Center. 

Use Case: Register a Product 

Actors: Producer, Sponsor, Administrator 

Purpose: To provide the Resource Center a digital product. 

Overview: Producer provides the Resource Center a link to a digital product. 

Sponsor decides to accept the link, which constitutes registering the 
product. 
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Actor Action 


System Response 


1. Producer browses through available 
registration elements and selects one. 

2. Producer fills in descriptive information 
and provides a link to the digital 
product. 

3. Producer clicks button uploading 
product. 

4. Sends message notifying 

Administrator of Producer's action. 

5. Sponsor selects product name and clicks 
button approving the product. 

6. Sends message notifying 

Administrator of Sponsor's action. 

7. Administrator selects product name and 
indicates to the System that selection 
should be visible. 

8. Makes product name visible to all 
users of Sponsor's registration 
element. 

This use case describes the current implementation of process to register products 

in the FDMS Resource Center. An analysis of the use case reveals some shortcomings. 
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First, how did the Sponsor k now a product was pending his decision? The System 
notified the Administrator of the Producer's actions, but it did not notify the Sponsor. 
Second, why did the System not inform the Producer of the Sponsor's decision? An 
alternative scenario to this use case occurs when the Sponsor disapproves registering the 
new product. In either case, it is a significant oversight not to notify the Producer of the 
outcome of his initial action. 

2. Authorize Release 

This second use case describes the fairly simple process of a Sponsor providing a 
Consumer access to a Resource Center product. 

Use Case: Authorize Release 

Actors: Sponsor, Consumer 

Purpose: To provide a Consumer access to digital products. 

Overview: Sponsor provides access to a product or a registration element 

(constituting a number of products) to a Consumer or set of Consumers. 


Actor Action 

1. Consumer contacts Sponsor and requests 
Consumer privileges for a Resource 
Center product. 

2. Sponsor selects product name or 
registration element (constituting a 
range of products). 
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Actor Action 


System Response 


3. Sponsor selects Consumer name jfrom a 
drop-down list and clicks the "Finish" 
button. 

4. Makes selected product or 
registration element visible to 
Consumer. Notifies Consumer via 
email message. 


This use case is straight-forward and describes a critical process for the Resource 
Center to provide utility to its users. But consider an alternative scenario in which the 
Sponsor agrees to provide many Consumers access to a product. Step 3 then becomes: 
"Sponsor selects each Consumer name one by one fi'om the drop-down list. Once 
complete, Sponsor clicks the 'Finish' button." This is still a straight-forward process 
unless the Sponsor has to select dozens of names firom the list. It would be an even 
greater chore if the names were unfamiliar to the Sponsor, e.g., the Consumers are firom 
another organization which has an interest in studying or reusing the Sponsor's products. 

The following chapter addresses these and other issues with the FDMS Resource 
Center. The intent is to enhance the Resource Center's processes so that they will be 
clear, informative, and useful to the DoD modeling and simulation community. 
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III. REQUIREMENTS 


A. INTRODUCTION 

This chapter defines the new requirements of the FDMS Resource Center. The 
requirements range from cosmetic changes of existing screens to refinements of current 
capabilities to definitions of entirely new FDMS processes. 

In general, each paragraph of this section describes a need and refers to a figure 
which illustrates the need. The resulting requirement is labeled with an “R” followed by 
a hierarchical number (R3, R3.1, R3.1.1, etc.) and separated from the text by a box. All 
the requirements are summarized at Table 3 at the end of this chapter. 

B. GENERAL REQUIREMENTS 

The FDMS is inconsistent when referring to the digital files which it catalogs and 
maintains. At times the files are called “documents”, “products”, or “resources”. The 
term “document” is ill-chosen because the FDMS hbraries can maintain non-documents 
like models and simulations implemented as executable files or databases. The term 
“resource” is not concise and connotes a business-like air to the FDMS tool (funds, assets 
and liabilities, income and expenditures, etc.). The term “product” best captures the 
useful nature of the digital files maintained and cataloged by FDMS libraries. 

R1 The FDMS libraries will refer to the digital files in its repository as 
“products”. 
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C. PRODUCER FUNCTIONS 

Producer Functions are the first of the five sets of user functions. The set of 
Producer Functions consists of four subordinate functions as depicted in Figure 2. 



Figure 2. Producer Functions. 

1. Design/Create 

The Design and Create Documents function is not automated in FDMS. The 
screen (Figure 3) clearly states that the user must create documents “external to the 
Toolset.” This information is useful but there are two ambiguities with the screen. First, 
the use of the term “documents” is misleading but has already been discussed in 
Paragraph III.A and in Requirement Rl. The second issue centers aroimd the terms 
“register” and “submit”. In FDMS, to “register” a product is to initially place it into the 
repository. Whenever a producer modifies an FDMS product, he has to “submit” the 
modified product rather than re-register it. This distinction is important to the FDMS 
conununity and should be made clear either explicitly on this screen or through a direct 
link. 

R2 The Design and Create Documents screen will clarify the difference 
between “register” and “submit”. 
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Design and Create Documents 


Defhvthr^: 

■ I>esign: The deih&^aie, purposeful: 
pl^hg to descrte a model ^ a 
scheme forinplementation of the model; 
to defne the nterha! elements of a - 
• • model: . 


(>je3te: To construct a resource; to 
physically, organize hformatipn recorded 
in text.^ images hto a dested fyrrpat 


► Native Dqcu merits are. created external to the. Toolset. You 
may use formats such as. Microsoft’Word document 
Microsoft PowerPoint Adobe Acrobat; HTML, XML.,. 

► Create the Document using a desired Tool, ' ■' 

► When you are ready to Register or Submit the Document •. 

click the appropriate button from the Producer Vievv. menu on • 
the left. , • , 


Figure 3. Design and Create Documents Screen. 


2. Register 

The Register New Product(s) function constitutes Producers’ requests to Sponsors 
to load and maintain products in the FDMS. It has two sub-functions: (1) a Producer can 
create a registration element and (2) he can register a product. 
a. Register News Products 

The Register New Products screen (Figure 4) suffers from a lack of 
clarity. It directs the Producer to “simply upload” a product or to create a hitherto 
imdefined “registration element.” Neither of these terms are defined nor can their 
meanings be accurately construed from the context. 
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R3 The Register New Products screen will clearly inform the user of his 
options regarding creating registration elements or registering products. 


R3.1 The screen will present the user with two options: to register a 
product or to create a registration element. 

R3.2 The screen will briefly define “registration element” so that the 
user can make an informed decision. 


Register New Pfpduct(s) 


Deiimthn: The fyrma! deliv&y of .3 resource . 

. fyr actus! hckjsion.hlhe rqaositdry. The : 

Producer has. the leadro!e to register anew 
resource with the admtoistrator. 

• Click Here to simply upload.your document(s). 

Click Here to create a Registration Element before uploading your 
■ . documerit(s)., , ' , 

' 

Figure 4. Register New Products Screen. 


b. Create Registration Element 

A registration element is analogous to a directory in the Unix and DOS operating 
systems: it is a device for a Producer or Sponsor to organize his modeling and simulation 
files. Registration elements are approved by Sponsors, and Sponsors govern what 
products are registered and “stored” in their registration elements. 

R4 The FDMS system will control the creation of registration elements. 
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(1) The workflow governing the creation of a registration 
element is depicted in “as is” system events in the sequence diagram at Figure 5. A 
problem with the workflow occurs in the first step when the Producer creates a 
registration element. He does not request the creation of a registration element, but 
actually creates one on the system. The system allows the Producer to create his 
registration element as a sub-element of a Sponsor’s existing registration element or 
imder the Administrator’s root registration element. A Producer can immediately start 
registering his products under the new registration element before the governing Sponsor 
approves it. Clearly, a Producer should not be able to use a registration element before it 
has been approved by the Sponsor. 

R4.1 The Producer will not be able to use a registration element and it 
will not be visible to users other than the Administrator until it is 
approved by the governing Sponsor. 

(2) A second problem with the workflow is that the Sponsor 
is not automatically informed when a Producer creates a registration element. Similarly, 
the Producer is not automatically informed when a Sponsor approves or disapproves a 
registration element the Producer created. This lack of notification burdens both the 
Sponsor and the Producer to manually check the registration status of the elements and 
products they oversee or are interested in. 

R4.2 The FDMS system will overtly notify the governing Sponsor and 
Producer during the various steps in creating a registration element as 
depicted in the sequence diagram at Fig 5. 
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- Solid arrows depict “as -is” system events 

- Dashed arrows depict “to-be” system events 


Figure 5. Registration Element Creation Sequence Diagram. 

(3) A Producer can create a registration element by completing 
the screen at Figure 6. The screen has some cosmetic errors in it, to wit: 

• The header. Register Product(s), and definition are incorrect. 
This screen is not used to register a product but instead is used to create a registration 
element. 

• The term “Registration Element” is imderlined suggesting that 
it is a hot-link to another page. It is not and, therefore, is potentially confusing to the 
user. 
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• Clicking the “Register” button in the top right comer does not 
complete the create-registration-element process as does the “Register” button at the 
bottom of the screen. It instead takes the user back to the previous Register New 
Products screen. 


R4.3 The Create Registration Element screen will clearly inform the 
user how to create a registration element. 

R4.3.1 The screen will have a clear header and definition. 

R4.3.2 The screen will not have misleading underlining. 

R4.3.3 The screen’s top “Register” button will be labeled to 
reflect its true “go back one screen” function. 


c. Register Produces) 

The process for a Producer to register a product mirrors the process to 
create a registration element (Figure 5) and, as such, suffers from the same deficiencies: 
the FDMS system fails to inform the Sponsor when a Producer submits a product for 
approval and the system fails to notify the Producer when the Sponsor approves or 
disapproves a product. As with the registration element process, this process 
unnecessarily burdens the Sponsor and Producer to manually check the FDMS libraries 
for product status. 

The Register Product(s) screen is straight-forward and clear except that it 
shares a fault of the Create Registration Element screen — it displays a deceptive 
“Register” button which takes the user back to the previous Register New Products 
screen. 
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R5 The FDMS system will control the submission of products for approval. 

R5.1 The system will overtly notify the governing Sponsor and 
Producer during the various steps in the submission of products for 
approval. 

R5.2 The top “Register” button on the Register Product(s) screen will 
be labeled to reflect its true “go back one screen” function. 
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3. Remaining Producer Functions 

The remaining two of the four Producer functions are in good order. The third 
function, Integrate/Modify, is, like the Design/Create function, not automated. The 
corresponding Integrate/Modify Documents screen instructs the user to modify registered 
products with tools “external to the (FDMS) toolset.” The instructions are clear. The 
title of the screen, however, should change “Documents” to “Products” as noted in 
Requirement R1. 

The fourth Producer function, Submit, instructs the user how to re-register a 
product which has been modified. This function and its corresponding screen are clear. 

D. SPONSOR FUNCTIONS 

The Sponsor, acting as the “traffic cop” in the FDMS libraries, controls the 
registration and access of products. To do this the libraries provide the Sponsor with four 
functions as depicted in Figme 7. The functions are similar in that they entail the 
Sponsor selecting names of products for approval or endorsement or selecting names of 
users for specific permissions to view or effect the products. 



Figure 7. Sponsor Functions. 
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1. Approve 

The Product/Registration Element Approval screen (Figure 8) is functional 
although aspects of it are misleading. Notably, the title of the screen is incorrect - this 
screen is used to approve products as well as registration elements. This error repeats 
itself in the table which displays “Registration Element” as the first column’s header 
when that column lists both registration elements and products. Less serious, but still 
potentially puzzling to the novice Sponsor, is the second column’s header, “User”. In 
fact, the only user of the screen is one who can approve or disapprove registration 
elements and products; that is, a Sponsor. The column header should reflect as much. 

R6 The Product/Registration Element Approval screen will be clear. 

R6.1 The screen header will be correctly labeled. 

R6.2 The headers of the first and second columns of the approval table 

will read “Product/Registration Element” and “Sponsor”, respectively. 



Figure 8. Product/Registration Element Approval Screen. 
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2 . 


Endorse 


The Product/Registration Element Endorsement screen (Figure 9) is nearly 
identical to the Product/Registration Element Approval screen and has similar 
deficiencies. The title of the screen does not reflect that registration elements are also 
endorsed on this screen. Additionally, two columns in the table are mis-labeled: the 
“User” column should be named “Sponsor” and the “Approved” column should be 
named “Endorsed.” These changes will improve clarity and minimize confusion. 


R7 The headers of the second and third columns of the approval table in the 
Product Endorsement screen will read “Sponsor” and “Endorsed”, respectively. 



Prod uct Endorse ment 

Defimtton: To approve of a resource.that wds produced under.the au^ic^'of another.sponsor , 



1, 'Date- * ' , 

t * Comment - - >'* [■ 

1 Test Registration Element 2 i Nathalie WDid^Ella i |sfl 

2001'02*20 19:34:35 

1 am just testing 







Test Registration Element 2b 

Nathalie Mbida-Elia 

Si 

2001-03-26 11:59:17 

Test 






Test Registration Eiement 2b1 

Bill Deng 

Si 

2001-04-2517:03:36 

test comments. 






Test Registration Element 2c 










Test Registration Element 2d j 



HHHHH 

HHHHHHHHHHIH 




BHHHHIii 


A Test I 



HHliHiHl 





IBHHHHi 

IIIIIBHHBHHHHHHH: 

NLE 001 Name I 




n 


Bidorse ^. 


Highlight the procix±ycxJ wi^. to Endorse on the grid above, then cHck on the •“Endorse" • 
button located below; th^^ • •' 


Figure 9. Product/Registxation Element Endorsement Screen. 
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3. 


Allocate and Authorize Release 


The Product Allocation and the Product Release Authorization functions are 
similar; they both allow the Sponsor to assign privileges to users regarding the use of 
products under the purview of the Sponsor. (There is a distinct difference between the 
two screens. The Product Allocation screen allows the Sponsor to assign Sponsor, 
Examiner, and Producer permissions to users. The Product Release Authorization screen 
only allows the Sponsor to provide access to a product (view or copy privileges) to a 
Consumer.) The screens are functional and clear (the Product Allocation screen is shown 
at Figure 10). A significant capability which these functions lack, however, is the ability 
to assign privileges to a group of users. 



Product Allocation 


, Deikuthn: To Assign ihe tasks of administration/ production^ examSiation, &id consumption of a resource to-specific groipe/pdividuafs 


■ Reflisli^on BementfProtJuot' 





JIWITT 


" Oat84.> 

.-.''ExamlTOr.'T 


j£ 

Test Registration Element 2 

Bill Deng 

2001-03-18 14:29:56 

Sj 

Si 

SI 


Daniel P. Sagan 

2001-03-22 16:32:47 

□ 

Si 

SI 


Jim Lin 

2001-03-1614:29:57 

Si 

Bj 

SI 


Kit Case 

2001-03-16 14:29:56 

SI 

SI 

SI 


Patrick Michael Humphrey 

2001-03-22 16:32:47 

□ 

Si 

SI 


Paul M Nelson 

2001-04-11 14:48:27 

Si 

SI 

SI 


Wayne Randolph 

2001-03-16 16:31:14 

□ 

SI 

SI 







Test Registration Element 2b 

Bill Deng 

2001-04-26 09:45:13 

□ 

SI 

□ 


Nathalie Mbida-Ella 


Si 

SI 

SI 







Test Registration Element 2b1 

Nathalie Mbida-Ella 

2001-04-11 17:37:35 

□ 

SI 

□ 








^ f AlIbcatB > 


Highlight the product you wish to Allocate on the grid above,, then click on the “Allocate" 
button located below the grid. 


Figure 10. Product Allocation Screen. 
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FDMS' current capability allows the Sponsor to assign privileges to only one user 
at a time. This, of course, is not a burden to a Sponsor who has only a small number of 
users interested in his products. A Sponsor with a large team, however, will have a 
somewhat inconvenient chore assigning privileges, one after the other, to his team. 

Consider a hypothetical example: The manager of a new Army missile program 
contacts the Defense Threat Reduction Agency (DTRA). He knows that DTRA has 
developed a computer model - registered in FDMS ~ which displays the downwind 
hazard of chemical agents by predicting surface winds and weather over the local terrain. 
The missile PM is interested in the wind predictive capabilities of the DTRA model for 
possible reuse in a simulation the missile PM is building to predict the accuracy of the 
missile. He asks the DTRA PM to allocate consiuner privileges to fifty members of the 
missile program's team. As shown in Figme 11, the DTRA PM will have to scroll 
through the entire list of FDMS users and individually pick out fifty unfamiliar names. 
That would be quite a chore, and entirely avoidable if the missile PM was able to group 
his team under the name MSL_SIM, for example. Then the DTRA PM would only have 
to pick one name off the list, and go on with his business. 

Clearly, then a Sponsor needs to be able to create groups of users and assign 
privileges to the those groups. This leads to the next set of requirements found on 
page 23: 

As of this writing, the subordinate requirements of Requirement R8.1 are met in 

the Modeling and Simulation Resource Repository (MSRR). As discussed in the 

Introduction, the MSRR is a separate but related modeling and simulation library 

developed and managed by the Defense Modeling and Simulation Office. There is an 
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effort currently underway which, if successful, will allow the FDMS to use groups 
created and maintained in the MSRR. If that effort is unsuccessful or caimot be 
implemented in a timely manner, the grouping requirements will have to be implemented 
directly into FDMS. 


Tp confirm that you want to Release: TRe^istratipn flement 2b 1, 
please complete the following' information then dick on the "Finish" button! 


You want to Release these access privieg^ 


CONSUMERrAccess^S 

CONSUIMER: Locate ri: . 
CONSUMER: Review 

jd ■, 



To.the following users: 


Case, Kit 1 

Chang, Angela 0 

Deng, Bill ' 

Dou^erty, Fran , 

Dowd, Mary Kate Si . . 


.. .. ^ 

Your Comments (if any)...- . , 



Figure 11. Product Release Screen. 
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R8 A Sponsor will be able to define groups and assign privileges to those 
groups. 


R8.1 A Sponsor will be able to create and modify groups. 

R8.1.1 Each group will have a unique name. 

R8.1.2 The Sponsor will have the option to add notes or 
explanatory comments about a group. 

R8.1.3 The system will display the names of users so that the 
Sponsor can select user names from the display to be members of 
his group. 

R8.1.4 A Sponsor will have the option of allowing other users to 
use his group or of restricting all other users from using his group. 

R8.1.5 A Sponsor will be able to modify a group he created. He 
will be able to change a group's name, update the notes about a 
group, add or delete members from the group, and change the 
restrictions governing others' use of the group. 

R8.1.6 Only the original Sponsor and the Administrator will be 
able to modify or delete a group. 

R8.2 A Sponsor will be able to assign FDMS privileges to a group in the 
same manner as he would to an individual user. 
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E. REQUIREMENTS SUMMARY 


Table 3 summarizes the requirements enumerated in this chapter. The author 
strongly believes that the implementation of these requirements into subsequent versions 
of the FDMS Resource Center will significantly improve the usability of the web-based 
repository. This, in turn, will encourage members of the DoD modeling and simulation 
community to exploit the Resource Center by registering and analyzing their own 
products in the repository and by reusing other registered products. This anticipated 
synergy will directly support the first and fourth objectives of the draft DoD Modeling 
and Simulation Master Plan (see Table 2). 


R1 

The FDMS libraries will refer to the digital files in its repository as 

“products.” 

R2 

The Design and Create Documents screen will clarify the difference 
between "register" and "submit." 

R3 

The Register New Products screen will clearly inform the user of his 
options regarding creating registration elements or registering products. 

R3.1 

The screen will present the user with two options: to register a 
product or to create a registration element 

R3.2 

The screen will briefly define "registration element" so that the 

user can make an informed decision. 


Table 3 Requirements Summary (Part 1 of 3) 


28 



R4 

The FDMS system will control the creation of registration elements. 

R4.1 

The Producer will not be able to use a registration element and it 

will not be visible to users other than the Administrator xmtil it is 

approved by the governing Sponsor. 

R4.2 

The FDMS system will overtly notify the governing Sponsor and 

Producer during the various steps in creating a registration 

element as depicted in the sequence diagram at Fig 5. 

R4.3 

The Create Registration Element screen will clearly inform the 

user how to create a registration element. 

R4.3.1 

The screen will have a clear header and definition. 

R4.3.2 

The screen will not have misleading underlining. 

R4.3.3 

The screen’s top “Register” button will be labeled to reflect 

its true “go back one screen” function. 

R5 

The FDMS system will control the submission of products for approval. 

R5.1 

The system will overtly notify the governing Sponsor and 

Producer during the various steps in the submission of products 

for approval 

R5.2 

The top "Register" button on the Register Product(s) screen will be 

labeled to reflect its true "go back one screen" function. 

R6 

The Product/Registration Element Approval screen will be clear. 

R6.1 

The screen header will be correctly labeled. 

R6.2 

The headers of the first and second columns of the approval table 

will read "Product/Registration Element" and "Sponsor", 

respectively. 


Table 3 Requirements Summary (Part 2 of 3) 
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R7 

The headers of the second and third columns of the approval table 

in the Product Endorsement screen will read "Sponsor" and 

"Endorsed", respectively. 

R8 

A Sponsor will be able to define groups and assign privileges to 

those groups. 

R8.1 

A Sponsor will be able to create and modify groups. 

R8.1.1 

Each group will have a unique name. 

R8.1.2 

The Sponsor will have the option to add notes or 

explanatory comments about a group. 

R8.1.3 

The system will display the names of users so that 
the Sponsor can select user names from the display to 

be members of his group. 

R8.1.4 

A Sponsor will have the option of allowing other 
users to use his group or of restricting all other users 

from using his group. 

R8.1.5 

A Sponsor will be able to modify a group he created. 

He will be able to change a group's name, update the 

notes about a group, add or delete members from the 
group, and change the restrictions governing others' 

use of the group. 

R8.1.6 

Only the original Sponsor and the Administrator will 

be able to modify or delete a group. 

R8.2 

A Sponsor will be able to assign FDMS privileges to a group 

in the same manner as he would to an individual user. 


Table 3 Requirements Summary (Part 3 of 3) 
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IV. DISCUSSION AND CONCLUSION 


A. DISCUSSION 

The FDMS Resource Center is not an immature product. Select organizations, 
such as the Army’s One Semi-Automated Forces (OneSAF) project team, are beginning 
to use the Resovurce Center extensively. The OneSAF team, for example, is charged to 
develop a computer-generated force (CGF) which can simulate a full range of military 
operations at the battalion and brigade levels. The purpose of the CGF is to test ideas and 
concepts in the development of future force structures, doctrine, and equipment. 
OneSAF uses the FDMS to catalog the various models it develops or acquires, to verify 
and validate those models, and to convert selected models into XML products using a 
common data interchange format. These “common” models can then interoperate and 
grow to form more complex and faithful models. 

Other DoD organizations can use the FDMS Resource Center as well, but as 
stated earlier, they are not required to use it. Encouraging the use of the Resource Center, 
and gaining the synergies borne of commonly-formatted, interoperable models, is largely 
a marketing chore which DMSO must pursue within the modeling and simulation 
community. But it is also a matter of providing ready access to a repository which is easy 
to use with intuitive and self-explanatory screens and applications. It is this second issue 
which this work attempts to address. 

The author took the role of the requirements analyst. Over a period of six weeks 
of mostly full-time work he studied the operation of the Resource Center, interviewed the 
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functional proponent, and had numerous discussions with the project manager and the 
lead designer/programmer. The product of this work, and the subsequent implementation 
of it into the Resource Center code, will favorably impact screen design, workflow, and 
user security and access. 

B. CONCLUSION 

Defining requirements in a clear and unambiguous style is the first step in 
software development. Although not drafted in a formal way, the requirements listed 
here are based on the FDMS Resource Center and the MSRR, each of which constitutes 
the ultimate in formal models - an existing implementation of a software product. The 
requirements, therefore, are easy to understand within the context of the existing FDMS 
Resource Center and, the author hopes, will not be difficult to implement. Doing so 
should significantly improve a novice user’s imderstanding of the organization and 
functionality of the FDMS Resource Center. 

There is further work available to improve and broaden the functionality of the 
Resource Center. Of particular note is the system’s email notification system referenced 
in Figure 5 — the messages themselves could be made more clear to the message 
recipients. Examiner functions, to include the analysis tools available in the Common 
Library, deserve additional scrutiny and optimization. Finally, a closer linkage with the 
MSRR may be possible and desirable to expand the pool of the Resource Center’s users. 
Improvements and expanded functionality in these areas can only improve the potential 
the FDMS Resource Center holds for the DoD modeling and simulation community. 
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